feat(settings): add "Keep window open when it loses focus" option#2875
Conversation
|
Isn't this already covered by our Open Links system preference... |
|
No, it is not. Gitify still closes when the window loses focus, no matter what I set there. This has nothing to do with the links. Does this behave differently on other platforms? |
|
Just to show what I mean. Note that I'm using only mouse and the focus follows the cursor. 2026-05-10.21-36-02-a.mp4 |
| visible={!window.gitify.platform.isLinux()} | ||
| /> | ||
|
|
||
| <Checkbox |
There was a problem hiding this comment.
Can we please move this above the openAtStartup option
Ty Aside: the window positioning really is proper broken on Linux🤢 |
Is that not a hyprland issue specifically? |
Yes, this is Hyprland specific. Tried it on Gnome and there it opens correctly near the tray icon. |
Summary
Adds an opt-in "Keep window open when it loses focus" checkbox to System settings (default off). When enabled, the Gitify popup stays visible after focus moves to another window — useful when triaging notifications side-by-side with the browser, an editor, or a chat client.
Why
By default, Electron menubar apps hide the popup as soon as it loses focus (the
menubarlibrary's blur-driven hide). That matches the glance-and-go menubar convention but actively gets in the way of side-by-side workflows: read a PR in the browser while keeping the notification list visible, drag-and-drop URLs into another tool, etc. On tiling WMs (Hyprland, i3, Sway) where there's no fixed "menubar" zone, the convention itself feels out of place.The setting is off by default, preserving existing behavior.
Where it lives
At the bottom of
Settings → System, after the existing checkboxes. One-line tooltip explains the behavior.Implementation notes for reviewers
The mechanism is purely JS-level.
menubar's blur listener short-circuits its own hide when the underlyingBrowserWindow.isAlwaysOnTop()returns true (node_modules/menubar/lib/Menubar.js:343-353). We toggle that flag from the renderer-driven setting via a new IPC event (UPDATE_KEEP_WINDOW_ON_BLUR). No window-manager hints or platform-specific paths involved — works uniformly on macOS, Windows, X11, and (verified) Hyprland.Small bug fix folded in. The existing
devtools-openedhandler insrc/main/lifecycle/window.tssetsalwaysOnTop=truefor DevTools usability. The matchingdevtools-closedhandler previously did not restore it, so opening and closing DevTools left the flag stuck on for the rest of the session. The newapplyKeepWindowOnBlursetter owns this flag's lifecycle, and thedevtools-closedhandler now restores it to the user's preference (falseby default, matching the prior intent). One line of behavior change, inseparable from owning the flag — calling it out so the diff doesn't look surprising.Naming across the IPC boundary. Renderer concept:
keepWindowOnBlur. Main-side setter:applyKeepWindowOnBlur(mb, value). The fact that we implement it viasetAlwaysOnTopis an implementation detail and not exposed in the public name.Behavior matrix
Escfalse✓ (was previously stuck on)true✓Test plan
main.Escstill hides it; tray icon click still toggles.alwaysOnTopreturns to the setting's current value (regression check on the bug fix above).pnpm test— 1038 tests pass; new tests coverapplyKeepWindowOnBlur,devtools-closedrestoration, the settings checkbox, and the IPC handler; Settings snapshot regenerated.pnpm checkandpnpm tsc --noEmitclean.